Field of the Invention
The present invention relates to a specific protocol extension scenario for telecommunications, namely the addition of a new system information block (SIB) type to message(s) transmitted in cellular applications such as, for example, a cellular network that uses Wideband Code Division Multiple Access (W-CDMA).
Related Art and Other Considerations
In a typical cellular radio system, wireless user equipment units (UEs) communicate via a radio access network (RAN) to one or more core networks (CN). The user equipment units (UEs) can be mobile stations such as mobile telephones (“cellular” telephones) and laptops with mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or car-mounted mobile devices which communicate voice and/or data with radio access network. Alternatively, the wireless user equipment units can be fixed wireless devices, e.g., fixed cellular devices/terminals which are part of a wireless local loop or the like.
The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by a unique identity, which is broadcast in the cell. The base stations communicate over the air interface (e.g., radio frequencies) with the user equipment units (UE) within range of the base stations. In the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks. The core network has various service domains, with an RNC having an interface to these domains.
One example of a radio access network is the Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN). The UMTS is a third generation system which in some respects builds upon the radio access technology known as Global System for Mobile communications (GSM) developed in Europe. The UTRAN (UMTS Terrestrial Radio Access Network) is the part of the network that is responsible for the radio transmission and control of the radio connection. The UTRAN is essentially a radio access network providing wideband code division multiple access (WCDMA) to user equipment units (UEs). The Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and GSM-based radio access network technologies, and has developed certain technical specifications (TS) relating to standardization efforts.
Other types of telecommunications systems which encompass radio access networks include the following: Advance Mobile Phone Service (AMPS) system; the Narrowband AMPS system (NAMPS); the Total Access Communications System (TACS); the Personal Digital Cellular (PDS) system; the United States Digital Cellular (USDC) system; and the code division multiple access (CDMA) system described in EIA/TIA IS-95.
There are several interfaces of interest in the UTRAN. The interface between the radio network controllers (RNCs) and the core network(s) is termed the “Iu” interface. The interface between a radio network controller (RNC) and its base stations (BSs) is termed the “Iub” interface. The interface between the user equipment unit (UE) and the base stations is known as the “air interface” or the “radio interface” or “Uu interface”. In some instances, a connection involves both a Serving RNC (SRNC) and a drift RNC (DRNC), with the SRNC controlling the connection but with one or more diversity legs of is the connection being handling by the DRNC. An Inter-RNC transport link can be utilized for the transport of control and data signals between Serving RNC and a Drift RNC. An interface between radio network controllers (e.g., between a Serving RNC [SRNC] and a Drift RNC [DRNC]) is termed the “Iur” interface.
The RNS (Radio Network Subsystem) controls a number of Base Stations in the radio access network. As part of the RNS, the radio network controller (RNC) controls the UTRAN. In fulfilling its control role, the RNC (Radio Network Controller) controls radio resources and radio connectivity within a set of cells. Such resources managed by the RNC include (among others) the downlink (DL) power transmitted by the base stations; the uplink (UL) interference perceived by the base stations; and the hardware situated at the base stations.
The topology of a radio access network can also be conceptualized in areas or units larger than cells. Taking the UTRAN as an example radio access network, a UTRAN Routing Area (URA) is a geographical area comprising one or more cells. Each URA is identified by a unique identity which is broadcast in all cells belonging to the URA. A URA can comprise cells controlled by more than one RNC. A URA with more cells in more than one RNC is overlapping between the RNCs, i.e. an overlapping URA.
As another example from UTRAN, a Location Area (LA) is a geographical area comprising one or more cells. Each LA is identified by a unique identity sent on the broadcast channel, in the same way as the URA. However, a location area is used by the core network to track the location of the UE (in idle mode and in connected mode), while the URA is used by the radio access network to track the location of the UE in connected mode. Typically, a location area is geographically larger than a URA. To each location area there is one of several RNCs having cells in that particular location area. A relationship between location area and RNC is stored in the core network.
Radio access networks typically have a particular signalling protocol employed between the radio access network and the user equipment unit to support the management of radio resources. For example, UTRAN has its Radio Resource Control (RRC) layer 3 signalling protocol. A user equipment unit in the RRC protocol operates in a state model conceptualized as having two modes: an Idle Mode and a Connected Mode. The Idle Mode is entered after power on. In Idle Mode there is no connection between the user equipment unit (UE) and the UTRAN. The least active UEs operate in the idle mode, in which UTRAN is unaware of the presence of the UE. The core network (CN), however, is aware of the Location Area (LA)/Routing Area (RA) in which the UE is located. The UE also informs the CN of changes in LA/RA. Furthermore, in case an incoming call is to be established, the CN initiates paging in all cells comprising the LA/RA in which the UE is registered.
When an RRC connection is established, the user equipment unit (UE) is assigned a U-RNTI and the user equipment unit (UE) enters Connected Mode. In Connected Mode, the RNC in charge of the RRC connection for this UE is denoted as the Serving RNC (SRNC). As illustrated by FIG. X, within Connected Mode there are four different states (in order of increasing activity level): URA_PCH; CELL_PCH; CELL_FACH; and CELL_DCH. In the first two states the UE is inactive, in the URA_PCH state the UTRAN knows the UE position at the UTRAN Routing Area (URA) level while in CELL_DCH UTRAN knows the UE position at the cell level. In the CELL_FACH state the UE is active but operates on a common channel, which is a channel shared with other UEs. In the CELL_DCH state the UE operates on a dedicated channel which is allocated only for that UE.
In the CELL_DCH state the UTRAN controls the mobility of the UE, i.e. it orders the UE to perform measurements and based on, e.g., those measurements performs such activities as, e.g., moving the UE to another cell, adding or removing cells from the active set (i.e., the set of cells actively used in the RRC connection). In the other states however, the UE normally decides which cell to move to, although this cell re-selection process is influenced by parameters provided by the network.
To facilitate operations such as those described above, the UTRAN broadcasts or transmits certain “system information” over the air interface which may be relevant for a large number of UEs in a cell. The system information includes information and/or parameters which are formatted into information elements (IEs). The parameters of the information elements (IEs) are utilized for various purposes such as, e.g., to control the cell re-selection procedure for a UE. The broadcast of system information in general is described, e.g., in Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) Protocol Specification (Release 1999), e.g., §§ 8.1 et seq.
For various reasons some parameters (IEs) of the system information need to be broadcast more often than other parameters (IEs). For example, some of the parameters (IEs) need to be broadcast more frequently because, e.g., they affect the access delay or because the information changes rapidly. On the other hand, other system information is broadcast less frequently to spare or save the limited radio resources.
To facilitate different scheduling of system information, the system information (e.g., the system information message) is partitioned into a number of different types of system information blocks (SIBs). This partitioning of the system information into system information blocks (SIB s) permits, among other things, transmission of each type of SIB to be scheduled independently and at different time intervals to accomplish the aforementioned objectives. The different types of system information blocks are distinguished by means of a “SIB type” information element.
Thus, the system information elements are broadcast in system information blocks. A system information block groups together system information elements of the same nature. Different system information blocks may have different characteristics, e.g., regarding their repetition rate and the requirements of the UEs to re-read the system information blocks.
As discussed in Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) Protocol Specification (Release 1999), e.g., § 8.1.1.1.1, the system information is organized into a tree. In this tree organization scheme, a “master information block” (MIB) gives references and scheduling information to a number of system information blocks in a cell. The system information blocks (SIBs) contain the actual system information. The master information block may optionally also contain reference and scheduling information to one or two “scheduling blocks”. These scheduling blocks give references and scheduling information for additional system information blocks. Scheduling information for a system information block may only be included in either the master information block or one of the scheduling blocks.
Typically, a channel known as the broadcast channel is used to transfer system information and thus to carry the system information blocks (SIBs). Unfortunately, the broadcast channel (BCCH) only supports transfer of data units of a fixed size. This can be a problem since many of the system information blocks (SIBs) have a size which exceeds the fixed size of the BCCH. Therefore, in order to support system information blocks with a size exceeding the BCCH limit, a technique known as segmentation is used. Furthermore, to use the broadcast channel (BCCH) efficiently, a concatenation mechanism is provided. These two mechanisms basically operates as follows: (a) system information blocks may be split into a number of different segments, and (b) a number of segments may be concatenated. The concatenation of a number of segments is called a system information message. The segmentation and concatenation of segments for system information blocks (SIBs) are described, e.g., in Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) Protocol Specification (Release 1999), e.g., § 8.1.1.1.3. The entire Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12) is incorporated herein by reference.
As indicated above, information about which SIB is broadcast at a certain moment is not only provided within the corresponding segments of a system information block (SIB) but also within the scheduling information that is included in the Master Information Block (MIB) and/or one or more Scheduling Blocks (SBs). Although this facility introduces some redundancy, it also makes the segmentation more robust and makes it possible for the UE to decode SIBs even when its scheduling information is not yet available.
The signalling specified in the existing RRC protocol (e.g., Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) Protocol Specification (Release 1999)) also provides two specific mechanisms for the possibility of future extensions or modifications to signalling messages. These future extension mechanisms are described, e.g., in RRC protocol (e.g., Technical Specification 3GPP TS 25.331 V3.17.0 (2003-12), Radio Resource Control (RRC) Protocol Specification (Release 1999) § 10.1.1 et seq. Briefly, one of the mechanisms for future extension of all messages is the critical extension mechanism. The critical message extension mechanism involves the definition of a new version of the message. In the new version of the message the transfer syntax may be completely different from the previous version of the message, except for the initial part that indicates the version. The second of the future extension mechanisms is the non-critical message extension. When the non-critical message extension is used, the transfer syntax of the existing message is just extended with new information. In the non-critical message extension case old receivers will still recognize the entire message apart from the newly introduced extensions.
Since system information messages are broadcast generally, they cannot be directed only towards mobiles that support a certain protocol extension. Consequentially, to maintain backward compatibility, only the non-critical extension message mechanism can be used for system information. Furthermore, for system information the extension mechanism has been defined only at the level of the system information blocks. This means that future extension is neither possible at the level of the segments nor at the level of the system information messages.
In the RRC protocol, the transfer syntax specifies the range of possible information element values for parameters. In some cases this range includes a number of spare values that are reserved for future extension. This is also the case for the message type information element. The RRC protocol (TS 25.331) explicitly specifies that the UE shall ignore broadcast messages (message sent on BCCH) having a type which it does not comprehend. In other words, if the UE receives an RRC message on the BCCH, PCCH, CCCH or SHCCH with a message type not defined for the logical channel type the message was received on, the UE shall ignore the message.
In the future there will certainly be a need to introduce new system information block types within the Radio Resource Control (RRC) protocol as defined within 3GPP TS 25.331. Such new block types will be needed when, in future protocol versions, the system information is extended with information that needs to be scheduled independently using the currently defined flexible scheduling mechanism. One way to add new system information parameters (which will be defined in future) could be to add the new parameters to existing system information blocks. However, simply adding new parameters to existing system information blocks (SIBs) may be problematic if the new parameters have distinct scheduling requirements and/or specific requirements concerning their validity that is different from the system information blocks (SIBs) where they are is added. Therefore, most likely it will be preferable to create one or more new system information blocks for these parameters. Creating a new system information block (SIB) will involve creating a new “SIB type” value for the new system information block (SIB), with each newly created SIB type thereby using one of the limited number of spare values defined for the “SIB type” information element.
Moreover, to complicate matters, the “SIB type” information element is actually included in a number of hosting information elements, and the number of spare values reserved for future extension is not necessarily uniform among the hosting information elements (note that one information element can be a component or information element of another (host) information element). For example, the information element “SIB type” is used in different segments, such as the information elements “Complete SIB” & “Complete SIB (short)”. Currently, thirty two values have been defined for this “SIB type” when included in these different information element s, of which only two of the values are spare values. On the other hand, the information element “SIB and SB Type” is used in IE “References to other system information blocks and scheduling blocks”, which is included in the MIB. Currently thirty two values have been defined for this IE, of which three are spare values. Yet differently, the information element “SIB type SIBs only” is used in the two information elements known as “SCCPCH Information for FACH” and “References to other system information blocks”. Currently thirty two values have been defined for this ie, of which five values are spare values. Hence, as seen from the foregoing, the number of spare values is not consistent among the host information elements.
One possible way to extend the SIB type is as follows: (1) use the last spare value to indicate that the SIB type is extended; and (2) add a non critical extension to the message in order to support further extensions in future. For example, if it is desired to add support for an additional seven SIB types, one would need to add a three-bit field. In this case the first thirty one SIB types can be signalled by means of the original SIB type, while SIB type 31 up to 37 can be supported by the non-critical extension. Value 7 (‘111’B) of the non-critical extension would then be reserved for further extensions.
However, as mentioned before, future extension for system information is only possible at the level of the system information blocks. This means that the approach proposed in the preceding paragraph only works effectively for the SIB type information elements that are contained in system information blocks. For the SIB type information elements that are included in the segments and in the system information message another approach would clearly be needed.
Thus, at present it is only possible to add one additional SIB using the current extension mechanism. Moreover, due to the lack of extension possibilities at the level of the SYSTEM INFORMATION message and the level of the segments, it is not apparent how additional system information blocks (SIBs) should be introduced.
What is needed, therefore, and an object of the present invention, is techniques or mechanisms for adding additional types of system information blocks (SIBs) to telecommunications transmissions.